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The International Space Station global positioning systems (GPS) receiver was activated 
in April 2002. Since that time, numerous software anomalies surfaced that had to be worked 
around. Some of the software problems required waivers, such as the time function, while 
others required extensive operator intervention, such as numerous power cycles. Eventually, 
enough anomalies surfaced that the three pieces of code included in the GPS unit have been 
re-written and the GPS units were upgraded. The technical aspects of the problems are 
discussed, as well as the underlying causes that led to the delivery of a product that has had 
numerous problems. The technical aspects of the problems included physical phenomena 
that were not well understood, such as the affect that the ionosphere would have on the GPS 
measurements. The underlying causes were traced to inappropriate use of legacy software, 
changing requirements, inadequate software processes, unrealistic schedules, incorrect 
contract type, and unclear ownership responsibilities. 


I. Introduction 

Traditionally, space vehicles use ground tracking to provide position and velocity information; and star 
trackers, sun sensors, Earth sensors, and/or magnetometers to provide attitude information. Ground tracking uses 
ground based antennas to determine the orbits of spacecraft, as well as orbital debris. The U.S. segment of 
International Space Station (ISS) has been using GPS as its primary source of information for position, velocity, 
attitude, and time since April 2002 1 . The ISS GPS receiver procured by NASA is a GPS/Inertial Navigation System 
(GPS/INS). The GPS/INS architecture has been used successfully in military aircraft, tactical missile, and ground 
applications for the past 10 years. Other configurations have been used successfully on more than a dozen space 
missions and are the primary navigator on multiple launch vehicles 3 . The ISS, Crew Return Vehicle (CRV), and 
Shuttle GPS/INS units were the first developed for space applications. 

The GPS/INS procured by NASA was intended to provide a ‘common’ navigation sensor that would fulfill the 
Space Shuttle, ISS, and CRV requirements. In theory, a common navigation sensor would provide cost savings. 
For the Shuttle, the GPS/INS was to replace the High Accuracy Inertial Navigation System (HAINS) and the 
Miniaturized Airborne GPS Receiver (MAGR). For ISS, the GPS/INS is the primary navigation, attitude, and time 
sensor for the U.S. segment of the ISS. For the Crew Return Vehicle, the GPS/INS was to be the primary 
navigation and attitude sensor. 

Unfortunately, the goal of developing a common navigation sensor was never fully realized. Shuttle’s GPS/INS 
used a different GPS receiver than the ISS/CRV GPS/INS and therefore required a completely different software 
interface due to the requirement to maintain transparency with the heritage Shuttle avionics system. 

Originally, the ISS and CRV GPS/INS units were similar, and the software interface was intended to 
accommodate both projects. However, after three years of development, the throughput of one of the processors was 
not capable of implementing the diverse system requirements for both mission applications so the software between 
the two programs diverged. Although the hardware for ISS and CRV was similar, the ISS program did not initially 
have any requirements for the accelerometers or gyros in the GPS/INS. However, now that the unit is operational, 
the ISS program is attempting to use the accelerometer data from the INS to provide real time feedback during re- 
boosts in the future. At the time of the delivery of the flight units, the only thing common between the GPS/INS 
units for all three programs was the inertial sensor hardware, which is still currently unused by ISS. 

Shuttle GPS/INS was cancelled after the GPS/INS phase 1 flight test and development program was 
completed 2 . CRV GPS/INS was cancelled when the CRV project was canceled in 2002. 

The Space Shuttle still uses its two star trackers to determine attitude and align the HAINS. The GPS/INS 
procurement for Space Shuttle was not intended to replace the star tracker functionality, only the HAINS and 
MAGR. The ISS does have star tracker, sun sensor, Earth sensor, and magnetometer assets on the Russian 



Segment that provide valuable independent attitude knowledge during time periods when the GPS attitude 
functionality is not usable. 

This paper will focus on the ISS GPS/INS. Lessons learned from Shuttle GPS/INS and Shuttle GPS can be 
found in References 4-7. 

For ISS, the GPS position and velocity solutions from the two GPS receivers are used as updates to the ISS 
flight software’s propagated orbital state, the GPS attitude solutions are used as inputs in the ISS flight software’s 
attitude filter, and the GPS time output is used to correct the ISS on-board clocks. The GPS position, velocity, and 
attitude solutions are all unfiltered when received by the ISS flight software, which then filters the position, 



Fig. 1 Block diagram of ISS GPS/INS. 

velocity, and attitude information for on-board use. Future releases of the ISS software will include a filter for time 
so that the time output can be used autonomously (currently the time output is only used when the operators 
manually sync the on-board clocks to the GPS/INS time output). 

For the ISS GPS/INS, the GPS receiver manufacturer provided the GPS hardware and the GPS navigation 
software. NASA provided the GPS attitude software that resides within the GPS receiver. The GPS/INS integrator 
provided the integrated GPS/INS, the INS hardware, as well as the System Processor (SP) software that reads in 
the GPS receiver data and formats it for output over the MIL-STD 1553B bus. The data from the GPS receiver 
navigation firmware are passed through the GPS attitude firmware to the SP. The SP software also included the 
Kalman filter needed by CRV to blend the inertial and GPS measurements, and a GPS -only filter intended for use 
on ISS. The GPS-only Kalman filter was never used by ISS due to operational complexities associated with using 
it. Figure 1 shows a block diagram of ISS GPS/INS and Figure 2 shows the ISS and the GPS Antenna Assemblies 
(AA). 

After three years of on-orbit experience, the GPS continues to be used as the primary navigation, attitude, and 
time data source for ISS; however, some problems surfaced during operations that were not discovered during pre- 
flight simulation tests or Space Shuttle flight tests. As a result, the software in the GPS attitude code was totally 



Fig. 2 ISS GPS subsystem. 



rewritten using a code standard, and new GPS attitude algorithms were developed that are uniquely suited for ISS. 
In addition, the software that processes the time output from the GPS receiver was rewritten, while the GPS 
navigation code received minor revisions. 

The re-written code has been delivered to the ISS program and the GPS/INS units were upgraded with the new 
software in November 2004 for the first unit and February 2005 for the second unit. The new software has had 
substantially fewer problems as will be discussed later. 

Table 1 ISS Navigation Requirements 

Semi major axis accuracy 1000 feet 3 sigma 

Position accuracy 3000 feet 3 sigma 

Attitude accuracy 0.5 degrees 3 sigma 

Time Accuracy 100 microseconds 3 sigma 

The requirements for the ISS are shown in Table 1. GPS alone can meet the semi-major axis and time 
requirements. However, the multipath environment on ISS is such that the unfiltered GPS attitude solutions can 
not meet the 0.5 degree requirement. Unfiltered GPS attitude data is filtered with rate gyro data by the ISS 
software, resulting in an attitude output which does meet the 0.5 degree requirement. 

The GPS implementation on the ISS includes four GPS antennas as seen in Figure 2. Three GPS antennas are 
required for three dimensional attitude determination calculations and one antenna is required for position, 
velocity, and time calculations. There are two GPS/INS units in the United State’s Lab Module, also shown in 
Figure 2. For manned space flight, the requirement is for a system to be two-fault tolerant, meaning that following 
two faults, the system still meets requirements. For the ISS implementation, the Russian Segment avionics provide 
the third string of redundancy so that if both of the U.S. GPS/INS units fail, the ISS can still navigate using the 
Russian assets. Prior to the activation of the GPS/INS units in April 2002, the ISS navigated and determined 
attitude safely using the Russian segment alone. 

Figure 3 shows a diagram of the U.S. and Russian segment navigation and attitude determination assets. 
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Fig. 3 ISS GNC overview. 
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Notice that the Russian Segment has three sets of computers for fault tolerance while the U.S. side has only 
two. The Russian segment was the first deployed and had to meet the two fault tolerant requirement in the absence 
of any U.S. assets. The U.S. and Russian segments exchange information. The U.S. segment can be in control (i.e., 
using the Control Moment Gyros to maintain attitude) while using the Russian attitude information as the source 
of attitude knowledge. Likewise, the Russian segment can be using thrusters to control attitude while using the 
U.S. attitude information as the source of attitude knowledge. The Russian segment has a much wider range and 
redundancy of sensors. 

II. A Brief History of GPS Space Based Attitude Determination 











GPS Antennas 


GPS attitude determination for spacecraft was demonstrated as feasible by RADCAL in 1995 s . GPS attitude 
determination for use in a closed loop control system was first demonstrated by the REX II spacecraft in 1996 9,10 . In 
preparation for determining the appropriateness of attempting to use a new technology for attitude determination 
on ISS, NASA expended considerable effort and resources to test GPS receivers on the Space Shuttle. STS-77 flew 
a predecessor to the GPS receiver used on ISS. The receiver was mounted in the Shuttle payload bay with 4 GPS 
antennas arranged in the same 1.5 meter by 3 meter configuration that the ISS uses 11,12,13 . The same GPS/INS unit 
that ISS uses was flown on STS-101 and STS-106 configured with the same software as the ISS GPS/INS units 
used when they were activated in April 2002. These two flights also had the GPS/INS mounted in the Shuttle 
payload bay with four GPS antennas arranged in a 1.5 meter by 3 meter rectangle to mimic the ISS GPS antenna 

configuration 1,14,15 
. Two additional 
flight tests were 
performed on 
STS- 100 and STS- 
108 using the 
same GPS/INS 
hardware, but the 
GPS/INS was 
mounted in a 
Shuttle avionics 
rack and was 
configured to use 
the Shuttle’s 



Fig. 4 Space Shuttle payload bay arrangement for STS-101 and STS-106. 


Miniature 

Airborne GPS Receiver (MAGR) GPS antennas. The STS-100 and STS-108 flight tests were primarily flown to 
demonstrate the entry performance of the GPS/INS for use on CRV: GPS attitude determination was not 
demonstrated on these flights 1 . 


Figure 4 shows the arrangement of the four GPS antennas and the mounting platform for the STS-101 and STS- 
106 missions. The antennas and the antenna configuration were the same for STS-77. The GPS attitude solutions 
were compared to star tracker solutions for STS-101 and STS-106. STS-77 did not fly a star tracker, and the 
Shuttle’s attitude solution was used for comparison for that experiment. 


In addition to the flight tests, the GPS/INS code was put through extensive ground testing. The formal test 
suite included four months of orbital simulations using a GPS RF signal generator and one month of testing using 
a roof top antenna. Informal testing was conducted over several years and included both roof top antenna testing 
and orbital simulations. NASA also conducted independent testing of the entire ISS Guidance, Navigation, and 
Control (GNC) System in a closed-loop environment using as much ISS hardware as possible, including two 
GPS/INS units. This testing has been on going since 2000. Despite this extensive testing which uncovered more 
than 200 anomalies, some problems were nonetheless encountered after the GPS units were activated on the ISS in 
April 2002. The next section describes the problems that were uncovered after the product had been delivered and 
accepted. 


A brief timeline of the significant milestones in the ISS GPS/INS development is shown in Table 2. 


Significant Events in ISS GPS/INS Timeline 

STS-77 May 1996 Demonstrate GPS attitude capability 


STS-101 and STS-106 


May and Sept. 2000 


Demonstrate the ISS GPS/INS in a 
space environment performing 
attitude determination 


STS- 100 and STS-108 

May and Dec. 2001 

Demonstrate the GPS/INS capability 
for CRV 

Activation of ISS GPS/INS units 
on the ISS 

April 2002 

Both ISS GPS/INS activated and 
incorporated into the U.S. segment of 
the ISS 

New firmware loaded into the 
ISS GPS/INS units 

Nov. 2004 and Feb. 2005 

Due to the many problems uncovered 
before and after the units were 
activated on the ISS, new firmware 
was developed and loaded into the 
units on orbit 


III. Problems Encountered that Required Operator/Mission Control Intervention 


A. Time Outputs Were Incorrect 

Time is critical to many applications on ISS, such as solar panel pointing and communication antenna 
pointing. After the GPS/INS had been activated by the ISS program, numerous time problems were uncovered. 
Fortunately, time problems previously uncovered during the flight tests on the Shuttle and ground testing led to the 
time requirement being waived. Had the ISS been configured to use the time from the GPS/INS autonomously, the 
time problems uncovered could have put the ISS at risk. However, the time function was managed using an 
alternate manual technique. 

The central clock for the U.S. segment of the ISS is the clock of the Primary Command and Control (C&C) 
computer, which is a radiation hardened Intel 386-based machine that broadcasts time to all other U.S. segment 
computers and other devices via the MIL-STD 1553B network. The clock of the C&C is not intended to be precise, 
and can have a clock drift of up to one second per day uncorrected. The C&C code was designed to be synched to 
GPS/INS and automatically track GPS time output, thus negating the need for a precision clock within the C&C 
itself. However, because the time outputs from GPS/INS have been so erratic, the C&C clock has never been 
autonomously synched to GPS/INS. 

Instead, flight controllers leave the C&C clock in local mode (where the local clock is allowed to drift and is 
not reset by the time output from GPS/INS). The drift can be coarsely metered in a positive or negative direction 
through daily manual adjustment commanded by the ground. Flight controllers compute onboard time error by 
comparing timestamps on downlink telemetry to the Mission Control Center central timing system and adjusting 
the clock metering rate daily. Using this workaround, the C&C clock is kept to within +/- 2 seconds of GPS system 
time. The error is acceptable, but is outside design specifications. Fortunately, the payloads that require the tighter 
requirement have not yet been deployed. 

Each of the time anomalies is discussed in detail below. 

The first time anomaly uncovered was that the output from the GPS/INS would not jump back to the correct 
time following long periods of tracking fewer than four satellites. It generally took periods as long as 19 hours for 
the problem to surface. It was discovered that logic put in place in the SP to accommodate the time intervals when 
SP was not receiving a time message from the GPS receiver caused problems following long outages. The GPS 
receiver did not output the time message due to the particular implementation of the integer resolution algorithm in 
the GPS attitude firmware. Once the SP’s clock and GPS receiver’s clock had drifted apart by more than 3.5 
seconds during the time message outages, the SP code didn’t think the time output it later received from the GPS 
was accurate, even though it was. During the time that the GPS attitude software, using an integer search 



technique, is searching thru the integers, all interrupts are disabled, which also means that no messages, including 
the time message, are output. The time output from the GPS receiver could cease for as long as 10 seconds, which 
the SP code perceived as time jumps. The problem in the SP code was a result of the SP code attempting to 
accommodate these perceived time jumps due to the loss of time message outputs from the GPS attitude firmware. 


The second time anomaly uncovered was that the GPS/INS time was observed to jump by several seconds. The 
cause of this particular problem was never fully understood; however, since the time code has been totally re- 
written the problem has 
ODRC Time not recurred. 
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Fig. 5 GPS/INS time compared to ODRC time. 


The third time anomaly 
uncovered was that the 
GPS/INS unit’s time was 
observed to jump by 1024 
weeks, an entire GPS 
epoch. This was traced to 
code in the GPS/INS that 
was attempting to use 
GPS leap seconds to 
determine how many GPS 
rollovers had occurred. 
Figure 5 shows an 
example of the time data 
from the GPS/INS on the 


ISS. The GPS/INS unit’s 


time is compared to the 

time stamp placed on the telemetered data by the Orbital Data Reduction Complex (ODRC). ODRC is the 
computer system in Mission Control that stores all of the flight data. The time stamp it places on the data is from 
its own clock, which is synced to Universal Time Coordinated (UTC). Notice the jump of 1024 weeks (1 GPS 
epoch) near the beginning of the plot. 


The data file for this plot contains the following: 
ODRC Time GPS/INS Seconds 


2002_142:02:08:38.296 

2002_142:02:08:39.296 

2002_142:02:08:40.296 

2002_142:02:08:41.296 

2002_142:02:08:42.296 

2002_142:02:08:43.296 

2002_142:02:08:44.296 

2002_142:02:08:45.296 

2002_142:02:08:46.296 

2002_142:02:08:47.296 

2002_142:02:08:48.296 

2002_142:02:08:49.296 

2002_142:02:08:50.296 


706068511 

706068512 

706068513 

706068514 

706068515 

7060685 1 6 jump 

867533 17" 4r 
706068518 
706068519 
706068520 
706068521 
706068522 
706068523 


Notice the time output at 2002_142:02:08:44.296 in which the GPS/INS time jumps back in time 1024 weeks, 
but recovers on the subsequent output. 

The time problems within the SP code were corrected by completely redesigning the time function and the new 
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Fig. 6 Time error in microseconds when tracking at least 4 satellites. 
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SP code has been tested 
in all of the scenarios 
that caused the problems 
noted above. This new 
code has been in use on 
the ISS since November 
2004 with no recurrence 
of the problem. The new 
time design utilizes the 
time message from the 
GPS receiver, rather than 
using the time part of the 
position and velocity 
message. This new 
design does not suffer 
from the flaw that the 
time in the position 
message is only updated 
when the receiver is able 
to calculate a position 
solution. Additionally, 
the new time design has 
been thoughtfully crafted 
to propagate time during 
position outages using 
the GPS receiver’s more 
stable oscillator, rather 
than the less stable SP 
oscillator. With the new 
design, the time 
propagates at the rate of 
the error in the last 

output of the GPS receiver’s oscillator drift rate. Previously, the SP propagated time using its clock, which drifts at 
approximately 35 microseconds per second, while the GPS receiver’s clock drifts at 1 to 2 microseconds per 
second. Under the new design, the time drifts at a lower rate than the drift rate of the GPS oscillator since the 
software compensates for the last measured drift rate. Unfortunately, one new problem has been uncovered that will 
occur when there are 15 leap seconds and will manifest itself as a time jump of entire GPS epochs. This problem 
will have to be corrected prior to the leap seconds reaching 15 (in a few years). Even though the GPS/INS units 
have been upgraded with the new software that fixes the time problems, the ISS is still not using the GPS/INS time 
autonomously. The time data from the GPS/INS units are being evaluated to ensure satisfactory software 
performance before attempting to use the time data autonomously. 


The original time design did meet the requirements when the GPS receiver was tracking enough satellites to 
determine position, and the requirements were written so that time only needed to meet requirements when the 
GPS receiver was determining position. Therefore, the software passed the initial tests, which were designed 
strictly to test conformance to the requirements. Subsequent tests have been designed that test the GPS/INS under 
conditions beyond the original requirements that are more strenuous and therefore more likely to detect problems. 
Figures 6 and 7 show the time error for the new GPS/INS code compared to a True Time GPS card during a static 
ground test. Figure 6 is for a time period when the GPS/INS is tracking at least four satellites, and Figure 7 
includes a period when the Radio Frequency (RF) port was disconnected so that GPS/INS was not tracking 
satellites. 
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Fig. 7 Time error in microseconds: GPS/INS RF port disconnected for weekend. 


B. 

GPS/INS Output a Not-A-Number 

On two occasions on February 11, 2003, almost an entire year after the activation of the GPS/INS units on the 
ISS, the GPS attitude code output an IEEE 754 Not-A-Number (0x7FFF OxFFFF). The Not-A-Number output 
caused the U.S. primary and the backup ISS Guidance, Navigation, and Control (GNC) computers to stop 
processing. Attitude control was handed off from the Control Moment Gyroscope (CMG)-based system on the U.S. 
segment to the thruster-based system on the Russian segment, resulting in loss of micro-gravity and requiring the 
use of carefully managed propellant supplies for control. Flight controllers manually pointed the high-rate S-band 
used for core system commanding, telemetry, and voice in an intense effort to maintain communications with the 
crew, while Ku-band communications for payload data, operations plans, and video were lost. The entire event cost 
one day of on-orbit operations. 

No viable work around could be found that would preclude this problem from recurring, so the GPS/INS units 
were left unpowered for several months to protect the vehicle.. During the time that the units were unpowered, a 
modification to the GNC flight code was developed and implemented that allowed the U.S. GNC flight computer to 
continue to function when the Not-A-Number was received. After the ISS GNC flight code was modified, normal 
operation of the GPS/INS units was resumed. The root cause of the Not-A-Number output from the GPS attitude 
code was never determined; however, all the attitude code that could have generated it has been re-written. No new 
occurrences of the Not-A-Number have been noted with the new software. 


C. Numerous Power Cycles 

The original attitude determination code exhibited the unfortunate tendency to reset itself under certain 
circumstances. This behavior was not seen in ground testing, or in any of the Shuttle flight experiments. When a 
reset occurs, certain parameters are cleared from memory and need re-initialization. This problem was fairly easy 
to work around, although flight controllers had to perform many more power cycles of the units than was originally 
envisioned. Typically two to three power cycles per week were being performed due to this particular problem. 

Another problem was found in the SP code that also required a power cycle to clear. The SP code would set a 
particular bit called a Subsystem Flag that is part of the MIF-STD 1553B protocol. The setting of this bit is 
intended to warn the user of the data to disregard the data in the message. This bit was setting every 2-3 months 
and the GPS/INS unit could only be recovered via a power cycle. The root cause of the setting of the bit was never 
definitively determined, although the vendor was able to determine a most probable cause. The code that was 
determined to be the most likely cause was removed. The new software in operation in the ISS GPS/INS units has 
not seen a recurrence of this problem. 

Although performing numerous power cycles doesn’t appear at first glance to be of much concern, the GPS/INS 
units were not qualified to a certain number of power cycles and it was unknown what effect, if any, the numerous 
power cycles would have on the life of the units. The numerous power cycles also increased the operator work load. 


The new software has dramatically decreased the number of power cycles from several times per week to once 
every 3-4 months. 


D. Low Position and Attitude Coverage 

The integer resolution scheme in the original NASA GPS attitude code was a search method designed for use in 
aircraft carrier phase tracking, as described in reference 16. This method requires an initial attitude estimate, 
which implies operational constraints. For many of the ISS maneuvers, it is not worth the time required to re- 
initialize the GPS receiver with an attitude estimate. Also, since the attitude input has to be an aviation legacy East- 
North-Up reference frame, the attitude update would have to be constantly updated to function properly when the 
ISS is flying in an inertial hold. Instead, for certain maneuvers, it was accepted that the GPS would not be 
outputting attitude solutions. For the inertial attitudes, the attitude estimate was input as the attitude of the ISS at 
one particular moment during the orbit. However, for the rest of the orbit, any attitudes that were output were 
incorrect since the attitude estimate was incorrect. This search method required that all interrupts be stopped 
during the search time, meaning that no position, velocity, or time messages (previously discussed) were output 
from the attitude code at these times. 
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Fig. 8 Attitude Fig. 9 Attitude error in degrees for orbit simulation with ISS multipath environment - new GPS attitude 
error in degrees firmware, 
for orbit 

simulation with ISS multipath environment - original GPS attitude firmware. 


Since the integer resolution scheme mentioned above was not well suited for ISS, the attitude code was 
reformulated using a new integer resolution method as part of the re-code effort. This new method simply 
accumulates measurements over a user defined interval and performs a batch solution for the attitude and the 
integers. The new method 17 assumes that the ISS is in either an inertial hold or a Local Vertical Local Horizontal 
(LVLH) hold, which are the only types of attitudes the ISS flies. 

Figures 8 and 9 show the attitude error during a 12 hour LVLH simulation, for the old and new attitude 
algorithm with the simulated multipath environment of the ISS (note that the axis scales are different). 

The coverage statistics for the original and new attitude algorithm for a four day simulation in which the ISS 
was placed in an inertial hold are shown in Table 2. The simulation includes the blockage of the ISS structure. 
Coverage is defined as the percentage of time that a fresh attitude or position solution is output. Notice the higher 
position and attitude coverage for the new method. The increased position coverage is due to the new integer 
resolution algorithm not obstructing data from being output. 


Table 2 Coverage Statistics Comparison 

Original Method New Method 

Position 23% 48% 

Attitude 15% 31% 


Unlike the original attitude determination firmware, the new firmware does not require an initial attitude 
estimate. The new firmware has more coverage and better standard deviation statistics. The standard deviation of 
the error is 26 degrees root mean square for the original method and 4 degrees root mean square for the new 
firmware. 


E. Navigation Problems 

There were also problems encountered with the GPS navigation solution passed by the SP code to the ISS GNC 
computer. These were traced to various root causes, but the symptom was very similar in each case. Position and 
velocity solutions slowly diverge from the true state. The ISS error checking tends to accept the diverging solutions 
as valid since the GPS receiver output slowly drifted from the true state, rather than outputting a single anomalous 

solution. Figure 10 shows 
an example of such a 
drift in semi-major axis. 
Semi-major axis 
combines the position 
and velocity outputs into 
a single number. For ISS, 
the estimated semi-major 
axis, when compensated 
for J2, is a fairly constant 
number. 

The drifts were traced to 
several sources. One was 
the receiver tracking 
satellites through the 
Earth ’ s atmosphere, 

which caused severe distortion of the pseudorange measurement. Another factor was the health message, which 
was output in a separate message from the navigation solution. It was occasionally being incorrectly associated 
with the previous navigation solution rather than the current navigation solution. 

The new firmware was modified to not track satellites more than 10 degrees below the local horizon to avoid 
tracking satellites through the Earth’s atmosphere. It was also modified to associate health messages with the 
proper navigation solution. 
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Fig. 10 Semi-major axis for May 11, 2002. 


F. Velocity Noise Due To Ionospheric Scintillation 


A. Velocity Noise Due To Ionospheric Scintillation 
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Fig. 11 GPS/INS velocity noise as compared to 
ground filter. 
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Fig. 12 Latitude and longitude for noisy GPS/INS 
velocity output. 


Velocity noise has also been observed in ISS 
GPS measurements. Reference 18 contains an 
analysis of both ISS and Shuttle measurements that 
show this phenomenon. It appears to be related to 
high ionospheric activity. Figure 11 shows the 
GPS/INS unit’s velocity noise as compared to a 
GPS ground filter, called the Spacecraft Position 
Optimal Tracking (SPOT) filter. 

Figure 12 shows the latitude and longitude of the GPS solution when the velocity was output with an error that 
exceeded 0.5 meters/second. These noisy outputs appeared to be clustered in similar patterns as described in 
reference 19 for ionospheric scintillation. 


There have been no firmware modifications 
made to attempt to alleviate the effects of the 
ionospheric scintillation. The ground filter and on- 
orbit ISS navigation firmware are able to filter these 
noisy outputs without any adverse system effects. 


B. Multipath Interference Caused by the 
Robotic Arm 

Early in the development of the GPS/INS, it was 
recognized that multipath signal interference would 



Hours 


Fig. 13 Measured differential carrier phase errors 
compared to GTD predicted differential carrier phase 
errors for SV24 and antennas 1 and 2 from STS-77 data. 


Diffraction code compared well to the measured results and that code was therefore selected to be used to predict 
the ISS multipath environment. Figure 13 shows the comparison between predicted and measured differential 
carrier phase errors for the STS-77 GPS data. 

The predicted environment was used as an input in the GPS simulations. The GPS simulation results were then 
used as input in a simulation to determine whether the ISS attitude filter could meet the 0.5 degree requirement. 
The results from that analysis indicated that U.S. GNC could meet the requirement. Comparison of the on-orbit 
U.S. filtered attitude solution to the Russian star tracker data indicate that the U.S. segment does meet the 0.5 
degree requirement under the multipath conditions that were analyzed pre-flight. However, a previously un- 
analyzed situation did cause the U.S. segment to be unable to meet its attitude performance requirements. 


Figure 14 shows the position where the Space Station Remote Manipulator System (SSRMS or robotic arm) 
was parked from May 26 - July 22, 2004, for viewing a spacewalk. When the SSRMS is parked over the GPS 
antenna array, it causes increased multipath and blockage that significantly degrades the GPS/INS performance. 
There are fewer solutions output and the solutions that are output are much noisier. This is primarily an impact 
when ISS is flying inertial attitudes, since GPS/INS attitude coverage in these attitudes is already low. From on- 

orbit experience, the coverage has been reduced 
enough that the attitude filters within the U.S. GNC 
IPS Antenna flight software could not remain reliably converged 
using the attitude data from GPS/INS. 

While the obvious solution appears to be to avoid 
parking the SSRMS near the GPS antenna array, it is 
often operationally impossible to do so. The 
complexity of activating and physically moving the 
SSRMS requires several hours of crew time, which is 
a carefully managed commodity. This results in the 
SSRMS often being parked over the array for weeks 
at a time. When the array is parked in the antenna’s 
field of view, flight controllers reconfigure the ISS 
GNC software to utilize attitude data from the 
Russian Segment GNC system, which is available to 
the U.S. GNC flight software as a backup to GPS. 



SSRMS 


Fig. 14 SSRMS Parked over GPS antenna array. 


H. GPS/INS Impacts on Mission Control State Vector Ground Processing 

Although there were no requirements on the GPS/INS to support state vector ground processing, once GPS/INS 
was operational on ISS, the benefits of such a filter became apparent. Although the position and velocity accuracy 
requirements for GPS/INS are sufficient to support antenna pointing for TDRS communications, they are not 
sufficient to support maneuver planning, or long-term orbital prediction and debris avoidance activities performed 
by Mission Control. A Mission Control based Kalman filter that processes the GPS data on the ground was 
developed to provide more precise orbit determination using high fidelity environment modeling. 

A serious challenge faced by filter developers was lengthy GPS/INS state vector outages during integer 
resolution for attitude determination by the GPS attitude code, which lengthened the time required for the filter to 
converge on a solution. Numerous telemetry problems also affected data quality. Extensive analysis of GPS/INS 
data and lengthy development of filter data pre-processor code was required to overcome GPS/INS and ISS 
telemetry deficiencies. 

The new firmware, with its new integer resolution scheme, does not have these long outages. 


I. Impacts of Poor State Vector Coverage Following Reboost 


ISS reboosts are performed several times a year to counter atmospheric decay and to support phasing 


requirements for Shuttle, Soyuz, and Progress vehicle rendezvous. In order to perform a reboost, attitude control of 
the vehicle is handed over from U.S. segment CMG control to Russian segment thruster control, and the Russian 
segment performs the reboost itself, normally by utilizing axial thrusters on a disposable Progress resupply vehicle 
docked to the rear port of ISS. 

Because there are currently no inertial measurement units in either the U.S. or Russian GNC systems, reboosts 
are performed with no direct measurement of acceleration. Onboard state vectors in the U.S. system are 
continuously updated through the burn by applying ground predicted accelerations and (when available) GPS state 
vectors. The accuracy of the onboard state vector after the burn must remain within 60 kilometers of truth in order 
to accurately point the ISS Ku-band communications system. 

Experience has shown performance variability in Russian reboost burns. For example, a reboost on Februrary 
11, 2003, was targeted for 6.0 meters/second, but problems with the Progress propulsion system resulted in an 
actual burn that was later calculated to be 4.1 meters/second. 

At the time, both Russian and U.S. flight controllers were aware that there had been a problem with the 
Progress, but were unable to establish the exact post-burnout state vector of ISS because of the lack of sensed 
acceleration data, poor state vector coverage from the GPS (due to the attitude code not outputting data since the 
post-burnout attitude was an inertial hold), and the time delay required to process ground radar data. 

The onboard state vector (which was updated with accelerations assuming a nominal predicted 6.0 
meter/second burn) eventually achieved an error of 165 kilometers before enough GPS and tracking data had been 
taken to establish the actual orbit of the vehicle and true reboost magnitude, nearly 10 hours after bum completion. 

Following this event, flight controllers modified the reboost sequence to fly a higher GPS/INS performance 
LVLH attitude for up to an orbit following reboost to increase the likelihood of acquiring post reboost state vectors. 
Flight controllers also began using accelerometers within the ISS payload system to provide an estimate of reboost 
performance. Unfortunately, these accelerometers were originally designed to monitor microgravity performance, 
not core system GNC performance, and are not always available to flight controllers in real time. 

Additionally, modifications have been made to GPS/INS firmware and U.S. GNC flight software to incorporate 
the currently unused inertial data from the GPS/INS into the U.S. GNC system by the end of 2006. 

IV. Lessons Learned 

The factors that contributed to the delivery of a GPS receiver for use on ISS that requires extensive operator 
intervention to function and extensive re-development and re-certification are discussed. 


A. Impacts of the COTS Philosophy 

The GPS/INS was procured under the philosophy that buying a product as close as possible to the vendor’s 
commercial off-the-shelf (COTS) product would be less expensive than procuring a product that was uniquely 
developed for a particular application. In this case, the cost savings were not realized, and the COTS philosophy 
contributed to the extensive software problems. The GPS/INS hardware was similar in nature to the COTS 
hardware, but the software requirements for the space application were very unique. The original software was 
developed for use in airborne applications, not space applications. The modifications required for space application 
were made without removing or changing the functionality of the code that was uniquely developed for the 
airborne application. The GPS attitude determination integer resolution technique developed for the airborne 
application required that the user input roll and pitch, and the software would determine heading. During the time 
that the software was determining heading, all message outputs would cease. This type of scheme makes sense for 
an aircraft on a runway that most likely has roll and pitch near zero and an unknown heading, but makes no sense 
for the ISS application. The ISS either knows its roll, pitch, and heading within 2 degrees or there has been some 
sort of malfunction. This particular integer resolution scheme, developed for the airborne application, contributed 
to many of the problems cited in this paper. One of the time problems was traced to the SP code attempting to 
accommodate the time outages caused by the integer resolution scheme. The poor state vector performance 



following re-boosts was traced to the lack of outputs from the GPS receiver caused by the integer resolution scheme 
continually trying to converge on a solution and therefore not outputting any state vector solutions. The new 
integer resolution scheme that was designed uniquely for ISS does not have these restrictions and does not lead to 
the problems cited. 

The problems noted with the state vector output were also traced to software designed for terrestrial 
applications. One of the causes of the state vector errors was the GPS code’s use of measurements from satellites 
that were below the local horizon. These signals exhibited significant delays caused by traveling through the 
Earth’s atmosphere. In a terrestrial application, it is impossible for a GPS receiver to track satellites below the local 
horizon, but in a space application such as ISS, satellites as low as 24 degrees below the local horizon have been 
tracked. As explained above, these low satellite signals typically induce more error than signals from satellites at 
higher elevations. The aforementioned code modification eliminated this problem by not allowing the GPS/INS to 
track satellites lower than 10 degree below the local horizontal. 

The COTS philosophy also dictated that NASA have limited insight into the vendor’s software since the 
development of the COTS software was not paid for by NASA and is considered proprietary. Even the software 
developed by NASA could not be obtained by the procuring NASA organization until after the development was 
complete. To mitigate the risk associated with having limited insight into the software, NASA chose to test 
extensively. The extensive testing did uncover many anomalies pre-flight, but many were only uncovered after the 
units were activated on ISS. One could argue that testing should have uncovered all of the anomalies; however, 
some surfaced after almost one year of continuous operations. It is extremely difficult to design enough tests to 
uncover those types of anomalies. The original code design was inherently flawed, and no amount of testing could 
fix the flaws in the time design or the attitude algorithms developed for airborne applications. Rather, the design 
needed to be tailored for the particular application. 


B. Requirements Changes 

Requirements for the GPS/INS common navigator were not well defined at the start of the program, most 
notably the CRV requirements. As new system requirements were determined, the changes resulted in new 
software requirements during the development. Even after the GPS/INS was operational on the ISS, new ways of 
utilizing the data from the GPS/INS were being defined, such as attempting to use the inertial sensor data for re- 
boost application. Additionally, the ISS has flown in different attitudes than were originally envisioned. These 
attitudes were not tested prior to the delivery of the product. One of the new attitudes was flown during the STS- 
114 mission in July 2005. This new attitude protected the Space Shuttle Orbiter from orbital debris by placing the 
orbiter behind the bulk of the ISS so that the ISS would protect the Orbiter’ s tiles. Although the GPS/INS 
requirements were not written to include this attitude, the new software was able to track satellites and produce 
valid solutions in this new configuration. Although ideally all requirements would be known completely at the time 
of procurement, realistically this is rarely the case. The contract type should be chosen to readily accommodate 
requirements changes. 


C. Firm, Fixed Price Contract Was Not Appropriate for This Procurement 

Relatively early in the development it was realized that the vendor was not going to be able to deliver the 
GPS/INS product for their firm, fixed price bid. Unforeseen requirement changes arose, which inevitably led to 
schedule and software development problems. In retrospect, this is easy to understand: an attitude determination 
GPS receiver integrated with an INS product had never been demonstrated in a space environment; therefore, its 
final development faced a significant degree of uncertainty and risk. The COTS hardware resulted in minimal 
impact but the software customized for space caused most of the uncertainty. Additionally, the extent of the 
modifications required to make the COTS product perform in the space environment were not clearly understood 
by the vendor when the firm, fixed price bid was made. Consequently, using a firm, fixed price contracting 
mechanism resulted in an inflexible contracting arrangement when technical problems and other unforeseen 
difficulties arose. 



D. Inadequate Software Quality Processes 

Purchasing COTS products when the vendor (which includes NASA in this case since NASA was a vendor as 
well as the customer) and NASA do not have adequate hardware and software processes in place can lead to 
significant operational problems. Both the vendor for the integrated product and the GPS receiver manufacturer 
had processes in place to ensure the quality of their hardware, and, as a result, the GPS/INS hardware has not had 
any problems. The navigation code was developed using a recognized coding standard to ensure the quality of the 
code. The SP code was developed using the vendor’s internal code standards for Department Of Defense 
applications during the ISS/CRV GPS/INS development. However, NASA did not follow any coding standards 
during the original development of the attitude determination software. 

As a result, the navigation code has had relatively few problems compared to the SP code and the attitude 
determination code. When the SP code was re-written, large portions of unused code were removed. When the 
attitude code was re-written, it was re-written using an accepted coding standard. The number of anomalies 
recorded for the upgraded software is less than twelve. The number of anomalies recorded for the original firmware 
is greater than 200. 


E. Unrealistic Schedules 

The original philosophy behind COTS procurements was that the development costs had already been absorbed 
and the item’s adaptation for use in space would be both faster and cheaper. Unfortunately, in the case of the space 
software development, this was not a good assumption and it led to very optimistic project schedules. 

Ultimately, unrealistically optimistic schedules only lead to poor quality software that will probably still be 
delivered late. The original ISS/CRV GPS/INS development schedule allowed six months for the delivery of the 
development units. The hardware arrived about one month late, but the software was not completed for another two 
years, after which it was tested, flown, and then extensively re-written due to its flaws. 

Although it was suspected that the project schedules were optimistic, there were two reasons to think the 
schedules could have been met: 1) GPS attitude determination had been demonstrated on flight experiments and 2) 
the GPS/INS was as close to the vendor’s COTS product as possible (the hardware changes were accomplished 
with minimal effort and few problems). However, it requires a significant amount of time and effort to take 
software technology from flight experiment demonstration to the robustness required for a manned spacecraft. 
Additionally, even though a product appears to work for an existing application, it is imprudent to assume that it is 
robust or will work well in a different environment. 

The unrealistic schedule impacted the quality of the software product because rather than create a realistic 
schedule that included time to create a well-planned software design, time to put in place coding standards, and 
time for testing of the custom software, the vendors worked long hours until they ultimately produced a system that 
functioned only marginally and was not robust. 

F. Ownership 

When dealing with multi-component boxes that must be integrated into a complex system, the ownership and 
responsibility for each component must be established early on. The integration of the software and hardware 
elements should be tested and verified to firm requirements at the unit level by the responsible parties. The flow of 
the requirements to each developmental item must be established and defined in early stages of the program and 
should not change if possible. 


V. Conclusion 


Implementing GPS on ISS required that many technical and contractual hurdles be overcome. The technical 
problems included software anomalies as well as physical phenomena that were not well understood, along with 



the often conflicting requirements that emerge with development of a device for multiple users. The concept of 
cost savings by using the same box on multiple vehicles was not realized, and actually led to conflicting 
requirements that introduced problems for the ISS implementation. The software anomalies were traced to 
inappropriate use of COTS software, inadequate requirements, and changing system requirements during short 
development cycles. The contracting problems included an inappropriate contract type and unrealistic schedules. 

Many of the problems noted here in the development of the ISS GPS/INS are similar in nature and cause to the 
software induced spacecraft accidents discussed in reference 22, including unrealistic schedules and poor software 
processes. 
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